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(54) Verfahren zur drahtlosen Kommunikation zwischen Terminals innerhalb eines lokalen 
Netzwerkes 



(57) Die Erf indung betrifft ein Verfahren zur drahtlo- 
sen Kommunikation zwischen Terminals (1,2,3) inner- 
halb eines lokalen Netzwerks, bei dem die Kommunika- 
tion zwischen auf den Terminals (1 ,2,3) laufenden oder 
mit diesen verbundenen hoheren Anwendungen durch 
Austausch von Datenpaketen ablauft und der Transport 
dieser Datenpakete zwischen den Terminals (1,2,3) 
drahtlos nach dem DECT-Protokoll Oder einem ahnli- 



chen Protokoll erfolgt. Erfindungsgemass wird auf der 
Ebene des DECT-Protokolls oder des ahnlichen Proto- 
kolls wenigstens ein fur eine hohere Anwendung kenn- 
zeichnender Parameter (Adresse), und/oder wenig- 
stens ein Parameter(ldentitat), der unter dem 
DECT>Protokoll bzw. dem ahnlichen Protokoll zur Kenn- 
zeichnung eines Terminals (1 ,2,3) verwendet wird, zwi- 
schen Terminals (1 ,2,3) ausgetauscht. 
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DECT-Verbindung zwischen diesen realisiert werden. Oblicherweise kommunizieren zwei mobile Terminals (PT: Por- 
table Radio Termination), in Fig. 2 z.B. Host 1 und Host 3, jedoch indirekt uber den FT des Netzwerks, der in Fig. 2 
vom Host 2 realisiert wird. Wenn das DECT-Merkmal Distributed Communications verwendet wird, kann auch direkt 
eine Verbindung zwischen den beiden als PT agierenden Hosts hergestellt werden. Im ersten Fall stellt Host 1 gemass 
5 EN 301 649 eine Verbindung zum FT Host 2 her, dessen Identitat Host 1 bekannt ist, und sendet das fur Host 3 
bestimmte Datenpaket. Host 2 empfangt das Datenpaket und leitet es an eine ihm zugeordnete hohere Anwendung 
weiter, die die DECT-ldentitat von Host 3 ermitteln muss, urn das Datenpaket zuzustellen. Im zweiten Fall muss Host 
1 selbst die Identitat von Host 3 ken n en. 

[0013] Viele hohere Anwendungen kommunizieren allerdings nicht direkt nach dem DECT-Protokoll, sondern tau- 

10 schen Datenpakete unter Verwendung anderer Datenubertragungsprotokolle aus, insbesondere Ethernet, Token Ring, 
IP, PPP, V.24. Diese Verfahren sind grundsatzlich fur die Kommunikation uber ein "anonymes" Transportmedium aus- 
gelegt, welches die angeschlossenen Terminals nicht von selbst unterscheiden kann, z.B. ein Datenkabel. Figur 2 zeigt 
ein Beispiel fur drahtgebundene Kommunikation zwischen einer Mehrzahl von solchen durch Kabel verbundenen Ter- 
minals. Die auf ihnen laufenden Anwendungen nutzen fur die Ubertragung von Datenpaketen das Ethernet-Protokoll 

15 als Obertragungsprotokoll, das die Ubertragung uber das physikalische Ubertragungsmedium, hier das Kabel, zwi- 
schen den verschiedenen Anschlusspunkten der Terminals an das Ubertragungsmedium regelt. 
[0014] Das TCP/IP Protokoll, dessen Referenzmodell in [1], Kapitel 41, Seiten 567-576 Oder in [3], Andrew S. Ta- 
nenbaum, COMPUTER NETWORKS, 3rd Edition, Prentice Hall PTR, New Jersey 1996, Seiten 28-39 beschrieben ist, 
wird als Netzwerkprotokoll genutzt und regelt die Ubertragung auf Netzwerkebene. Jeder Host hat eine Ethernet- 

20 Adresse, die vom Hersteller der vom Host benutzten Ethernet-Karte zugewiesen wurde, und eine Oblicherweise vom 
Netzwerkadministrator zugewiesene TCP/IP Adresse. Die einem Terminal zugeordneten hoheren Anwendungen kon- 
nen ebenfalls eigene Adressen haben. Zum richtigen Routen eines Datenpakets zwischen zwei Anwendungen mussen 
die Ethernet- und die TCP/I P-Adresse des Hosts bekannt sein, auf dem die Empfanger-Anwendung residiert. Denn 
sowohl das Ethernet- als auch das TCP/I P-Protokoll sind verbindungslose Protokolle, d.h. es wird keine direkte Ver- 

25 bindung zwischen zwei Terminals aufgebaut, sondern jedes Datenpaket wird auf das "anonyme" physikalische Uber- 
tragungsmedium, hier uber das Kabel, gegeben und von jedem weiteren Terminal empfangen. Jedes dieser weiteren 
Terminals uberpruft, ob das Datenpaket eine der eigenen IP- oder Ethernet- Adressen aufweist. Das Datenpaket'wird 
dann nur von dem Host, fur den es tatsachlich bestimmt ist, verwertet, wahrend es von den anderen Hosts verworfen 
wird. 

30 [0015] Es ist bekannt, bei einer derartigen Kommunikation zwischen hoheren Anwendungen die DECT-Technologie 
als drahtloses Transportmedium fur die Ubertragung von Datenpaketen anzuwenden, z.B. um ein drahtloses lokales 
Netzwerk aus einzelnen Terminals aufzubauen. Jedes Terminal erhalt uber ein DECT-Modul die Moglichkeit, drahtlos 
zu kommunizieren. Die DECT-Technologie ersetzt in diesem Fall das oben beschriebene Kabel, wahrend die Kom- 
munikation der hoheren Anwendungen davon unbeeinflusst ablauft, im obigen Beispiel uber die Protokolle TCP/IP und 

35 Ethernet. Entsprechend konnen DECT-ahnliche Protokolle verwendet werden, z.B. PWT 

[0016] Ein typisches Szenario dieses sogenannten DECT/Ethernet Interworking ist im DECT-Profil EN 301 649 
DPRS (DECT Packet Radio Service) beschrieben und in Figur 3 schematisch dargestellt. Dabei residieren die drei 
Protokolle DECT, Ethernet und TCP/IP in jedem Host. Jeder Host hat eine vom Hersteller der Ethernetkarte zugewie- 
sene Ethernet-Adresse, eine vom Netzwerkadministrator zugewiesene TCP/I P-Adresse und einestatische DECT Iden- 

40 titat, die vom Hersteller des vom Host benutzten DECT-Moduls vorgegeben wurde. Des weiteren kann der Host weitere 
dynamische, wahrend der Subskriptionsphase zugewiesene DECT-ldentitaten haben. Die Ubermittlung eines Daten- 
pakets von Host 1 zu Host 3 wird auf der Netzwerk-Ebene vom TCP/I P-Protokoll geregelt. Das Ethernet-Protokoll 
regelt die Ubertragung zwischen verschiedenen Zugangspunkten zum physikalischen Ubertragungsmedium, z.B. ei- 
nem Kabel, und das DECT-Protokoll sorgt fur die drahtlose Ubermittlung, z.B. anstelle des Kabels. 

45 [0017] Bei den bekannten Verfahren, bei denen DECT als drahtloses Ubertragungsmedium fur einen auf einem 
Internetprotokoll basierenden Datenaustausch eingesetzt wird, wird DECT also wie ein "anonymes" Ubertragungsme- 
dium behandelt: Samtliche Datenpakete werden unabhangig von ihrem Zielhost durch DECT-Verbindungen an alle 
Hosts ubermittelt, dabei jedoch nur von den Zielhosts verwertet. Dadurch wird die Ubertragungskapazitat, die bei der 
drahtlosen Kommunikation im Gegensatz zur drahtgebundenen ohnehin knapp ist, stark beansprucht. Die Eigenschaf- 

50 ten von DECT oder ahnlichen Technologien als "nicht anonymes" Ubertragungsmedium werden nicht genutzt. 

[0018] Zwar sind sogenannte Adress Retrieval (Resolution) Protokolle (ARP) bekannt, die auf TCP/IP und Ethemet- 
Ebene einem Terminal die Ermittlung des Ethernet- und TCP/I P-Adresspaars eines weiteren Terminals ermoglichen. 
Die Kenntnis der Ethernet- und TCP/I P-Adresse des Zielterminals ist notwendig fur das korrekte Routing von Daten- 
paketen, die fur eine auf dem Ziel-Terminal laufende hohere Anwendung bestimmt sind. Beim Adress Retrieval Protokoll 

55 generiert das initiierende Terminal, das ein Datenpaket an einen Host mit einer besttmmten IP-Adresse senden mochte, 
ein kurzes Datenpaket (Address-Resolution-Datenpaket), das uber eine spezielle Ethernet Multicast Adresse an alle 
Hosts des Netzwerks gesendet wird. Das Datenpaket enthalt die eigene IP- und Ethernet-Adresse des initiierenden 
Terminals sowie die IP-Adresse des Ziels-Hosts (Ziel- 1 P-Adresse) und die Aufforderung (REQUEST) an den Ziel-Host, 
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[0028] Nachfolgend werden Beispiele fur erfindungsgemasse Prozeduren und deren Einsatzmoglichkeiten unter 
Bezugnahme auf die Zeichnungen beschrieben. Es zeigen schematisch: 

Fig. 1 Ein Beispiel fur Kommunikation zwischen drei Terminals nach dem DECT-Protokoll (Stand der Technik); 

Fig. 2 ein Beispiel fur Kommunikation zwischen drei Terminals nach dem Ethernet- und TCP/I P-Protokoll (Stand 
der Technik); 

Fig. 3 ein Beispiel fur Kommunikation zwischen drei Terminals in einem DECT-LAN; 

Fig. 4 ein Beispiel fur den Ablauf einer Prozedur zur Identitatsermittlung (FT-initiiert, verbindungslos); 

Fig. 5 ein weiteres Beispiel fur den Ablauf einer Prozedur zur Identitatsermittlung (PT-initiiert, verbindungslos); 

Fig. 6 ein weiteres Beispiel fur den Ablauf einer Prozedur zur Identitatsermittlung (PT-initiiert, verbindungslos); 

Fig. 7 ein weiteres Beispiel fur den Ablauf einer Prozedur zur Identitatsermittlung (verbindungsorientiert); 

Fig. 8 ein Beispiel fur den Ablauf einer Prozedur zur Adresszuweisung (FT-initiiert); 

Fig. 9 ein weiteres Beispiel fur den Ablauf einer Prozedur zur Adresszuweisung (PT-initiiert); 

Fig. 10 ein Beispiel fur den Ablauf einer Prozedur zur Abgabe von Adressinformation (FT-initiiert); 

Fig. 11 ein weiteres Beispiel fur den Ablauf einer Prozedur zur Abgabe von Adressinformation (PT-initiiert); 

Fig. 12 ein Beispiel fur den Ablauf einer selbstandig von einem Terminal ausgelosten Prozedur zur Abgabe von 
Adressinformation. 

[0029] Die Figuren 1 bis 3 wurden bereits in der Beschreibungseinleitung beschrieben. Die Erfindung wird beispiels- 
weise in einem Umfeld gemass Figur 3 eingesetzt. 

[0030] Gemass einer ersten Ausbildung der Erfindung erf ragt ein erstes Terminal auf der Ebene des DECT-Protokolls 
Oder des ahnlichen Protokolls die Identitat eines Terminals mit einer bestimmten, dem ersten Terminal bekannten 
Adresse ("Identity Resolution" Prozedur). Dazu sendet das Terminal eine Meldung bzw. Anfrage, das diese Adresse 
enthalt. Alle Terminals, die diese Anfrage empfangen, vergleichen die ubermittelte Adresse mit der Adresse bzw. den 
Adressen der ihnen zugeordneten Anwendungen. Das Terminal, das die angefragte Adresse hat, sendet eine Antwort- 
meldung an das erste Terminal, in der es seine Identitat angibt. Diese an das erste Terminal ruckgemeldete Identitat 
wird dann zusammen mit der bekannten Adresse abgespeichert und kann zum Aufbau von Adresstabellen und schlies- 
slich zum korrekten Routen von Daten zwischen den hoheren Anwendungen uber DECT verwendet werden. In einer 
Anfrage konnen mehrere Adressen gesendet werden. Im Falle von mehreren Adressen konnen auch mehrere Ant- 
worten an das erste Terminal zuruckgesendet werden. Die Prozedur kann von jedem Terminal eingeleitet werden, 
wobei verbindungslose oder verbindungsorientierte Prozeduren verwendet werden konnen. 

[0031] Ein Beispiel fur den Ablauf der "Identity Resolution" Prozedur ist in Figur 4 dargestellt. Der Host 2, der hier 
die Funktion eines DECT-FT (Fixed radio Termination) oder eines HyP (Hybrid Part, siehe EN 300175-1 V1.6.0, 
2001 -09, Seite 1 0) hat, verfasst eine verbindungslose Anfrage 4 (Identity-Resolution-Request). Diese enthalt beispiels- 
weise einen Identitatsteil und einen Adressteil. Im Identitatsteil sind die Identitat oder die Identitaten der Terminals 
enthalten, an die die Anfrage 4 gesendet wird. Beispielsweise wird die Anfrage 4 mittels einer Gruppenidentitat an alle 
Terminals dieser Gruppe, hier die als PT agierenden Hosts 1 und 3, gesendet. Im Adressteil sind die Adresse oder die 
Adressen der Anwendungen enthalten, zu denen die entsprechende Identitat des Terminals erfragt wird, im vorliegen- 
den Beispiel die Adresse von Host 1 . Bei Empfang der Anfrage 4 uberprufen die Hosts 1 und 3 die ubertragenen 
Identitaten (Verfahrensschritt 5). Wenn diese mit einer der Identitaten des Hosts 1 bzw. 3 ubereinstimmt, vergleicht 
der Host 1 bzw. 3 die ubertragene Adresse mit den eigenen Adressen (Verfahrensschritt 6), ansonsten wird die Anfrage 
ignoriert. In Figur 4 stimmt die ubertragene Adresse mit einer Adresse von Host 1 uberein, der daraufhin eine Antwort 
7 im verbindungslosen Modus an den initiierenden Host 2 ubertragt. Die Antwort 7 enthalt die als ubereinstimmend 
festgestellte Adresse und vorzugsweise die Identitat des Terminals/Hosts 1 . Gegebenenfalls kann die Identitat von 
Host 1 auch aus anderen Quellen ermittelt werden, z.B. anhand der fur den Verbindungsaufbau zum anfragenden 
Terminal verwendeten PMID-lnformation (Portable MAC Identity). 

[0032] Host 3, dessen Adresse nicht passt, verwirft die Anfrage 4 (Verfahrensschritt 8). Das initiierende Terminal 
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[0037] Figur 8 zeigt schematisch den Ablaut einer solchen, vom als FT agierenden Host 2 eingeleiteten Prozedur 
zur Adresszuweisung. Der FT baut eine Verbindung zum PT Host 3 auf und ubertragt eine Meldung 11 , mit der er um 
Adresszuweisung bittet (Application-Parameter-Assign-Request). Die Meldung 1 1 enthalt vorzugsweise wenigstens 
ein Informationselement, mit dem angegeben wird, fur welche Anwendung welche Parameter zugewiesen werden 

5 sollen. In Figur 8 soil Host 3 eine IP- Adresse XYZ zugewiesen werden. Bei Erhalt dieser Meldung 11 Gberpruft der 
PT Host 3 die ubertragenen Parameter und bestimmt, ob diese der betreffenden Anwendung zugewiesen werden 
konnen. Falls dies der Fall ist, sendet Host 3 an Host 2 eine Annahme-Meldung 1 2, mit der der Vorschlag angenommen 
wird (Application- Parameter- Assign- Accept). Falls der Vorschlag zuruckgewiesen werden soil, sendet Host 3 eine ab- 
lehnende Meldung, mit der dieses mitgeteilt wird (hier nicht dargestellt). Diese kann Alternati worsen lage Oder Infor- 

10 mationen zur Ursache der Zuruckweisung enthalten. Der als FT agierende Host 2 kann die genehmigte Adresse von 
Host 3 in seine Adresstabelle ubernehmen (Verfahrensschritt 9). 

[0038] Figur 9 zeigt ein Beispiel fur den Ablaut einer PT-initiierten "Application Address Allocation" Prozedur, die hier 
vom als PT agierenden Host 1 eingeleitet ist. Diese verlauft unter Vermittlung des als FT agierenden Hosts 2 ab. Host 

1 sendet nach Verbindungsaufbau zum Host 2 an diesen eine Anfrage-Meldung 11 ', mit der um Parameterzuweisung 
is gebeten wird. Host 2 weist die Parameter nicht selbst zu, sondern stellt eine weitere Verbindung zu Host 3 her und 

ubertragt die Anfrage 11 wie im Beispiel Fig. 8. Wie bereits beschrieben (Fig. 8), bestatigt Host 3 den Vorschlag mit 
einer Annahme-Meldung 12 oder weist ihn zuruck. Der vermittelnde Host 2 teilt die Annahme Oder Ablehnung dem 
initiierenden Host 1 mit einer Meldung 12' mit. Die Verbindungen zu Host 1 und Host 3 werden gelost. Host 1 und Host 

2 tragen die zugewiesenen Parameter in ihre jeweiligen Adresstabellen ein (Verfahrensschritte 9, 9'). 

20 [0039] In einer weiteren vorteilhaften Verfahrensvariante kann ein initiierendes Terminal in einem DECT-LAN ein 
weiteres Terminal mit einer bestimmten Identitat zur Angabe der seinen Anwendungen zugeordneten Adressen an das 
initiierende Terminal veranlassen, indem es eine entsprechende Meldung an das Terminal sendet. Diese "Application 
Address Information" Prozedur kann verbindungsorientiert oder verbindungslos, PT- oder FT- initiiert ablaufen. 
[0040] Figur 10 zeigt ein Beispiel fur eine verbindungsorientierte von einem FT, hier Host 2, initiierte "Application 

25 Address Information" Prozedur. Host 2 generiert eine Meldung 13, mit der ein weiteres Terminal, hier Host 3, um 
Angabe bestimmter Parameter gebeten wird (Application-parameter-information-request). Diese Anfrage 13 enthalt 
vorzugsweise wenigstens ein Informationselement, das wenigstens einen Anwendungstyp, hier Ethernet, und einen 
Parametertyp, hier eine Adresse, angibt, zu denen Host 2 Informationen wunscht. Bei Erhalt dieser Meldung 13 uber- 
pruft Host 3 die ubertragenen Daten und sendet eine Antwort 14, in der er die angefragten Werte, soweit bekannt, 

30 angibt (Application-parameter-information-respond). Diese Daten tragt der anfragende Host 2 in seine Adresstabelle 
ein. Wenn Host 3 zu einem oder mehreren Parametern keine Daten bekannt sind, sendet er eine ablehnende Meldung 
(Application-parameter-information-reject), in der er dieses mitteilt (nicht dargestellt). Diese Meldung kann Informatio- 
nen uber die Ursache enthalten, weshalb die gewunschten Daten nicht vorhanden sind. Nach Erhalt der Antwort 14 
wird die Verbindung zwischen Host 2 und Host 3 wieder gelost. 

35 [0041] Die beschriebene verbindungsorientierte "Application Address Information" Prozedur kann auch von einem 
als PT agierenden Terminal eingeleitet werden. Dieses generiert eine Meldung, mit der der FT des DECT-LANs um 
Unterstutzung gebeten wird. Diese Meldung enthalt neben den bei der FT-initiierten Prozedur enthaltenen Daten auch 
die Identitat des Terminals, fur das die Informationen verlangt werden. Der FT fuhrt dann die Prozedur wie in Fig. 10 
gezeigt aus und teilt dem anfragenden PT das Ergebnis in einer entsprechenden Antwortmeldung mit. 

40 [0042] Figur 11 zeigt ein Beispiel fur eine verbindungslos ablaufende, vom als FT agierenden Host 2 eingeleitete 
"Application Address Information" Prozedur. Host 2 sendet eine Anfrage 13 (Application-parameter-information-re- 
quest) an alle weiteren Terminals des DECT-LANs, hier Host 1 und Host 3. Diese Anfrage 13 enthalt einen Adressteil, 
der die Identitaten der angesprochenen Terminals angibt, beispielsweise eine Gruppenidentitat. Die Anfrage 1 3 enthalt 
weiterhin einen Teil, in dem den Anwendungstyp, hier Ethernet, und der Parametertyp, hier eine Adresse, angegeben 

45 sind, zu denen Host 2 Informationen wunscht. Wenn die ubrigen Terminals 1 , 3 die Anfrage 13 empfangen, prufen sie 
zunachst, ob ihre Identitat mit der angegebenen Identitat ubereinstimmt. Wenn dies der Fall ist, wird die Anfrage 13 
bearbeitet und die begehrten Informationen in einer Antwortmeldung 14 (Application-parameter-information-respond) 
zuruckgesendet, andernfalls wird sie ignoriert. Wenn einzelne Parameter nicht vom angesprochenen Host 1 bzw. 3 
zur Verfugung gestellt werden konnen, wird dies in einer ablehnenden Antwort (Application-parameter-information- 

50 reject) vorzugsweise mit der Fehlerursache mitgeteilt. Der anfragende Host 2 tragt die von den beiden Hosts 1 bzw. 

3 erhaltenen Daten in seine Adresstabelle ein (Verfahrensschritt 9). 

[0043] Diese Prozedur kann auch von einem PT eingeleitet werden. Dieses lauft analog zum in Fig. 5 beschriebenen 
Verfahren ab, indem der als PT agierende Host 1 bzw. 3 den als FT agierenden Host 2 mit einer entsprechenden 
Meldung um Unterstutzung bittet. Host 2 fuhrt dann die Prozedur wie in Fig. 11 gezeigt durch, falls er nicht bereits 
55 selbst die gewunschten Daten besitzt, und teilt dem anfragenden PT das Ergebnis mit. Sowohl der anfragende Host 
als auch der als FT agierende unterstutzende Host tragen die ermittelten Daten in ihre lokale Adresstabelle ein. 
[0044] In einer weiteren vorteilhaften Weiterbildung der Erfindung stellt ein Terminal eines DECT-LANs von sich aus 
ohne eine Anfrage von einem anderen Terminal Parameter seiner ihm zugeordneten Anwendungen, insbesondere 
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'nformat,onselementeabgewandelt werden. VomS^v^T^JT' k6nnen bereits defi ™*e 

struktron emer S-Format oder B-Format DECtSIo Z , EN 3 °° 1 75 " 5 an ^gebenen Regeln zur Kon 

aut DECT-Ebene. bat triable 

=d^; 0 -S 

[0048, Einweiteres^orrnationselement^ 

L J .igende Tabelle ze,g» eine mag,i che Grundstruktur des ^ 1 , p- ^ m ^ 



Bit: 



0/1 
ext 



« APP-PA R AMETER-TYPEg 
Length of Contents (L) 

Application type J 



List with one or more Parameters types 



Octet: 

1 

2 
3 
4 



L+2 



ist beispielsweise wie folgt kodiert, wobei auch 



weitere 



Bits 


8 


7 


6 


5 


4 


3 




0 


0 


0 


0 


0 


0 




0 


0 


0 


0 


0 


1 




0 


0 


0 


0 


0 


1 


LJ 


0 


0 


0 


0 


1 


0 




0 J 


0 


0 


0 


1 


0 



1 

0 

1 

0 

1 



0 
0 
0 
0 
0 



Bedeutung 



Ethernet (802.3) 

IP (RFC1700, RFC2460, RFC2373) 

Token Ring 

PPP 

USB 
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Bits 



Bedeutung 



Adresse 
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(fortgesetzt) 



Bits 


7 


6 


5 


4 


3 


2 


1 


Bedeutung 




0 


0 


0 


0 


0 


1 


0 


Anderer Parameter 



[0052] Die folgende Tabelle zeigt eine mogliche Grundstruktur des "Application-Assigned-Parameter" Informations- 
elements: 



10 



Bit: | 8 



0/1 



0/1 



I 



I 



« APP-ASSIGNED-PARAMETERS» 



Length of Contents (L) 



Application type_1 



Parameter 1 



Parameter n 



Application type_k 



Parameter 1 



Parameter n 



Octet: 
1 

'2 
3 

3a 
3n 
k 

ka 
kn 



25 



30 



[0053] In das Informationselement konnen verschiedene Gruppen von Oktetts aufgenommen werden, wobei jede 
Gruppe vorzugsweise wie unten beschrieben definiert wird. Ein Erweiterungsbit zeigt gemass den DECT-Regeln an, 
ob mehr als eine Gruppe enthalten ist. 

[0054] Der Protokolldiskriminator (Application Type) (Oktett 3) ist so kodiert, wie oben beim "Application Parameter 
Type"-lnformationselement gezeigt. 

[0055] Die folgende Tabelle zeigt die Struktur und Kodierung der einzelnen Parameterfelder: 



Bit: |8|7|6|5|4|3|2|1| Octet: 



M 


Type of parameter 


k 


0/1 


Length of parameter 


k+1 






1 


Length of parameter 




Parameter value 


k+p 



[0056] Der Parametertyp (Oktett k) ist wie oben gezeigt kodiert, wobei das M bit (Oktett k) beispielsweise wie folgt 
kodiert ist: 



Bits 8 


Bedeutung 


0 
1 


Keine weiteren Parameter 
Weitere Parameter 



[0057] Ein Beispiel fur ein gesetztes "Application-Assigned-Parameter" Informationselement, das die Ethernet 
Adresse AC-DE-00-00-80 und die IP Adresse 128.10.2.30 ubermittelt, ist in der folgenden Tabelle gezeigt: 
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Bit: 



I 7 I 6 | 



M=0 



M=0 



'0 



« 



■ 5 I 4 | 3 | 2 

APP-ASblGNE D-PARAMETF R^ 
h of Contents /n = i« /~~*~*~x 



length of Contents (L) =? 16 /ni^f 
Application Type ~ ~~ 



;» 



0000 001Q 



Type of p arameter = qqq qqqi 
Length of p arameter = 48 (bits) 

ra motor w-,i. _ Z TZZl T^rr-r — 



Parameter value = 1100 1010" 
1110 1101 
1000 0100 
0000 0000 
0000 0000 
0000 100Q 



Application Type 2 = OoorTnTrvT 
Type of parameter = qq q 0001 

I onntk r^t _ . — • 



1 uuu , 

Length of p arameter = 3 27hit^T 

ramofor _ ~ — — 



Parameter value = 1000 0000' 
0000 1010 

0000 0010 

0001 1110 



Octet: 
1 
2 
3 

3a 

3b 

3c 

3d 

3e 

3f 

3g 

3h 

4 

4a 
4b 
4c 
4d 
4e 
4f 



' HrH~™ *~«~~.-. 

cecr*—™ 0 „„, a afe „ Bpr , atend „ ^^TSS™S,^«- — » 

Literaturverzeichnis 
[0062] 

[-1 *n, D. ^ mE cO«U«AT,ONS HANDBOOK, ORC PRESS, Boca „„„ 1997 

2 — ~, „„ « 2 , , ^ ^ VMaa 2mo 

.3, A— S. T _. COMpuTER neworks m p;emte m ^ ^ ^ ^ 

Paten tanspruche 

Terminate (1, 2, 3) ausgetauscht wird. nZe ' ChnUn9 eines Te "™a<s d. 2. 3) verwende. wird, (.dentita.) zwTsS 
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anderen Terminal zugeordneten Identitat oder die empfangene Identitat zusammen mit der dem anderen Terminal 
(1, 2, 3) zugeordnete Adresse abspeichert. 

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass ein erstes Terminal (1 , 2, 3) auf der Ebene 
5 des DECT-Protokolls oder des ahnlichen Protokolls die Identitat eines Terminals (1 , 2, 3) mit einer bestimmten, 

dem ersten Terminal (1 , 2, 3) bekannten Adresse erfragt und eine gegebenenfalls ruckgemeldete Identitat zusam- 
men mit der bekannten Adresse abspeichert. 

4. Verfahren nach einem der vorangegangenen Anspruche, dadurch gekennzeichnet, dass ein anfragendes Ter- 
10 minal (1 , 2, 3) zur Feststellung der Identitat eines Terminals (1 , 2, 3), das eine bestimmte, dem anfragenden Ter- 
minal bekannte Adresse hat, die Ubertragung einer Meldung mit wenigstens dieser Adresse an wenigstens ein 
weiteres Terminal veranlasst, vorzugsweise an alle Terminals des lokalen Netzwerks, wobei jedes Terminal, das 
diese Meldung empfangt, die Qbereinstimmung von ihm zugewiesenen Adressen mit der ubertragenen Adresse 
feststellt und im Falle der Qbereinstimmung die Ruckubertragung einer Meldung mit seiner Identitat und vorzugs- 

15 weise auch der ubertragenen Adresse an das anfragende Terminal (1, 2, 3) veranlasst ("Identity Resolution"- 

Prozedur). 

5. Verfahren nach einem der vorangegangenen Anspruche, dadurch gekennzeichnet, dass ein erstes Terminal (1 , 
2, 3) auf der Ebene des DECT-Protokolls oder des ahnlichen Protokolls wenigstens eine Adresse eines Terminals 

20 (1, 2, 3) mit einer bestimmten, dem ersten Terminal (1 , 2, 3) bekannten Identitat erfragt und eine gegebenenfalls 

ruckgemeldete Adresse zusammen mit der bekannten Identitat abspeichert. 

6. Verfahren nach einem der vorangegangenen Anspruche, dadurch gekennzeichnet, dass ein anfragendes Ter- 
minal (1, 2, 3) zur Feststellung wenigstens einer Adresse eines Terminals (1, 2, 3), das eine bestimmte, dem 

25 anfragenden Terminal (1 , 2, 3) bekannte Identitat hat, die Ubertragung einer Meldung mit wenigstens dieser Iden- 

titat an wenigstens ein weiteres Terminal veranlasst, vorzugsweise an alle Terminals (1, 2, 3) des lokalen Netz- 
werks, wobei jedes Terminal (1 , 2, 3), das diese Meldung empfangt, die Qbereinstimmung von ihm zugewiesenen 
Identitaten mit der ubertragenen Identitaten feststellt und im Falle der Qbereinstimmung die Ruckubertragung einer 
Meldung mit wenigstens einer Adresse eines Terminals (1 , 2, 3) und vorzugsweise auch der ubertragenen Identitat 

30 an das anfragende Terminal (1 , 2, 3) veranlasst ("Application Parameter Resolution"-Prozedur). 

7. Verfahren nach einem der vorangegangenen Anspruche, dadurch gekennzeichnet, dass ein erstes Terminal (1 , 
2, 3) auf der Ebene des DECT-Protokolls oder des ahnlichen Protokolls wenigstens einer Anwendung, die auf 
einem weiteren Terminal (1 , 2, 3) lauft oder mit diesem verbunden ist, wenigstens eine Adresse zuordnet, wobei 

35 eine diese Adresse enthaltende Meldung an das weitere Terminal (1 , 2, 3) ubertragen wird. 

8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass das weitere Terminal (1 , 2, 3) an das erste Terminal 
(1, 2, 3) eine Meldung sendet, mit der das erste Terminal (1 , 2, 3) um Bekanntgabe wenigstens einer Adresse fur 
wenigstens eine dem weiteren Terminal (1, 2, 3) zugeordnete Anwendung gebeten wird, wobei vorzugsweise 

^0 Informationen uber die betreffenden Anwendungen ubertragen werden, und das erste Terminal (1 , 2, 3) die zuge- 

wiesene Adresse dem weiteren Terminal (1, 2, 3) in einer weiteren Meldung ubertragt. ("Application Parameter 
Allocation"-Prozedur) 

9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass das weitere Terminal (1, 2, 3) die ubertragene zu- 
45 gewiesene Adresse uberpruft und eine Meldung an das erste Terminal (1 , 2, 3) sendet, falls es die Zuweisung 

ablehnt, wobei die Meldung vorzugsweise Informationen uber die betreffende Anwendung und/oder uber alterna- 
tive Adressen enthalt. 

10. Verfahren nach einem der vorangegangenen Anspruche, dadurch gekennzeichnet, dass ein erstes Terminal (1 , 
so 2, 3) auf der Ebene des DECT-Protokolls oder des ahnlichen Protokolls ein weiteres Terminal (1 , 2, 3) zur Uber- 
tragung wenigstens einer, vorzugsweise aller Adressen der dem weiteren Terminal (1 , 2, 3) zugeordneten Anwen- 
dungen an das erste Terminal (1, 2, 3) veranlasst und dass das erste Terminal die ruckgemeldeten Adressen 
abspeichert, vorzugsweise zusammen mit einer vorzugsweise ebenfalls abgefragten und ruckgemeldeten Identitat 
des weiteren Terminals (1 , 2, 3). 

55 

11. Verfahren nach einem der vorangegangenen Anspruche, dadurch gekennzeichnet, dass ein anfragendes Ter- 
minal zur Feststellung von wenigstens einer, vorzugsweise einer Mehrzahl von Adressen eines anderen Terminals 
die Ubertragung einer Meldung an wenigstens ein weiteres Terminal veranlasst, vorzugsweise an alle Terminals 
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HOST 1 



PT (HyP) 



HOST 2 



FT (HyP) PT(HyP) 



HOST 3 



< 



Establish connection with Host 3 



> 



{IDENTITY-RESOLUTION-REQUEST} 
<App assigned parameter.Application type =Ethernet, 
Parameter 1=Type Addresses + Value> 

i 



10 



/ Is Host_3's "S. 
S Application address = 
^^Application Address?/^ 



{IDENTITY-RESOLUTION-REJECT} 



NO 



Release connection with Host 3 



> 



Establish connection with Host 1 



{IDENTITY-RESOLUTION-REQUEST} 
<App assigned parameter.Application type =Ethernet, 
Para mete r_1=Type Addresses + Value> 

__£ 



Is Host_ 
Application address = 
Application Address?, 



d dress = ^ 



> 



YES 

{IDENTITY-RESOLUTION-RESPOND} 
<Portable ldentity=Host 1 ld>, 
<App assigned parameter.Application type = Ethernet, 
Parameter_1=Type Addresses + Value> 



< 



Release connection with Host 1 



> 



Add an entry in the 
"DECT Identity-Application 
addresses resolution table" 
for Host 1 



Figur 7 
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11 



{APPLICATION-PARAMETER-ASSIGN-REQUEST} 
<App parameter assigned.Application type =IP, 
Parameter_1 = .Addresses type + Value> 



<is Application and 
jdress acceptable 
1 y 

YES 



{APPLICATION-PARAMETER-ASSIGN-ACCEPT} 

««- - 



Release connection with Host 3 



< 


f 


9 




Add an entry in the 






"DECT Identity-Application 






addresses resolution table" 






for Host 3 






i 






r 



> 
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11 



{APPLICATION-PARAMETER-ASSIGN-REQUEST} 
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< 

12 
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address acceptable l y 
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ASSIGN-ACCEPT} 



YES 



Release connection with Host 2/1 





9' 












< 




Add an entry in the 




Add an entry in the 
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"DECT Identity-Application 


addresses resolution table" 




addresses resolution table" 


for Host 3 




for Host 3 
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